LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Occasionally, we want to defer panel updates and most often it is just the current front panel. Unfortunately, the defer property node absolutely requires a wired reference to the panel.

In the past it always took me quite a while with many dead ends to get it right. For example, one might try to do the obvious and "right-click...link to..Panel", but that does not work! I challenge anyone to get that panel reference in under 60 seconds starting with a generic property node from the palette. Just try! (Hint. After selecting the right class (VI Server...VI...VI), the drop down lists it as "Front Panel" and not "Panel".)

The idea would be to allow defer nodes without a wired panel reference and they would just act on the current front panel and not break the VI.

Note that the panel reference defaults to the current VI and does not require a reference, so why can't the defer node do the same?

(Note that we also have this old idea, which would simplify things...)

The Class Browser (Ctrl-Shift-B) is a little-known LabVIEW feature that makes it much easier to work with property-based class hierarchies in LabVIEW (VI Server, DAQmx, VISA, Sys Config, your own .lvclasses, etc.). The Class Browser search function is particularly helpful when you aren't exactly sure what property or method you need, or if it even exists. Unfortunately, the search results are often very difficult to navigate, as in this example:

I was looking for a property or method relating to locking controls on the front panel, so I searched for "lock". Over 1000 results were returned. But the results include a tremendous number of duplicates. If there is a property of a parent class (like the Is On Block Diagram? property of the Generic class in the screenshot above), then that property will be duplicated for all child classes of that parent class... in this case, there are hundreds of children of the Generic class! It took me a few minutes just to scroll through all these duplicate results to finally find what I was looking for (the "Lock Objects" method of the Pane class).

Idea: Only show the parent class property/method in the search results of the Class Browser window. Do not show child class entries for that same property/method.

In the example above, if duplicates had been removed, then my "lock" search would have returned 49 results, which is a much more reasonably sized list of results to dig through.

Add structure on bare wires

Current state:

Suppose you have some neat code that bundles/unbundles elements from either a typedef-ed cluster or a class. You even provided free space in case some names are changed in the future:

But then, when you change an element's name to a longer one, this happens:

Now, to have the same neat code as before, you have to surgically select, move and realign the Bundle/Unbundle nodes correctly:

Since these nodes are resized in a centered manner, to keep neat code without the need to realign everything by hand, you must provide free space both on the left AND on the right.

Remark 1: The same issue can happen when you select another item with a different width in the Bundle/Unbundle node.

Remark 2: It seems all nodes of class "Named Bundler" and "Named Unbundler" are concerned. So that also includes the Waveform / Digital Waveform / Digital Data Bundlers/Unbundlers.

Proposed Idea:

When a Named Bundler or a Named Unbundler updates its own size (either because the typedef is changed or because the user selects another item), it resizes to the right instead of resizing from the center. So, if you want to provide space for further modifications, you only need to put space on the right (and not both on the left and the right). Also, I find that resizing to the right is quite consistent with the left alignment of the element names.

Regards,

Raphaël.

View All (3)

Very often, I create concrete classes that only inherit from LV Object and interface(s). By default these have the same wire appearance as LV Object, which provides very little information when looking at block diagrams. Ask is to add a selection dropdown to choose which ancestor to inherit wire appearance from so I can easily make all descendants of an interface have the same wire appearance.

Bonus would be to default to the parent interface while creating the interface if you select exactly 1 interface and LV Object as parent during the class creation dialog.

Problem

I find myself wanting to Ctrl+Drag to add/remove diagram space INSIDE of a structure without actually resizing the structure itself AND without modifying any other frames – I just want to clean up the visible diagram that I am working on.

However, this is not how LabVIEW currently works – the structure itself is also resized, and the space within other frames of the structure are resized as well (outward/inward from the same point as the Ctrl+Drag action), which can mess up both the code in other frames as well as the code outside the structure.

Proposed Solutions

Option 1: Lock Structure Size Add the ability to lock the size of structures (or perhaps only lock them from growing during creating/removing space), so that I can use Ctrl+Drag to create/remove space without impacting the structure and the code around it. This would be similar to "Auto Grow" but would perhaps be an "Allow Grow" or "Lock Size" setting.

Option 2: Modifier Key Use the Shift modifier during Ctrl+Drag and Ctrl+Alt+Drag to NOT resize the containing structure. This would maintain backward compatibility while adding the new functionality.

Why This Matters

When working on complex VIs with multiple frames in structures, it's frustrating to have simple diagram space cleanup operations affect the entire structure and surrounding code. This feature would allow developers to better organize/tidy the code within individual frames without the ripple effect of resizing everything (in other frames and outside the structure).

View All (2)

View All (5)

Starting from LV 2023 Q1, the terminals height of some nodes was harmonized to 16 pixels to improve diagram readability by reducing the amount of needed wire bends.

Some candidates for this harmonization were omitted though:

- Data nodes of timed structures (timed loop, timed sequence).

- I think pretty much all of FPGA nodes (IO nodes / methods / properties, FIFO / memory / register / handshake methods, IP integration, high-troughput math nodes, ...).

Example with a Timed Loop:

The idea is to also allow RT and FPGA developments to benefit from this harmonization.

View All (4)

No autogrow while typing

View All (1)

In previous versions of LabVIEW (including 25Q1), if you right-clicked on a wire, you could navigate directly to the Breakpoint Manager. With the merging of probes and breakpoints in 25Q3, the "Breakpoint Manager" has been replaced with the "Debug Window". However -- there's no longer a right-click shortcut on wires to navigate to it. I'd like to see this brought back, as it's a more intuitive location to find it than the View menu. Finding it for the first time after the switch wasn't obvious either, because of the name change.

(And yes, I'm aware that there's now a keyboard shortcut to directly access the Debug Window (ctrl+d) which I'll be using in the future, but I wouldn't expect most users to have this memorized.)

A very common task when operating with 2D pictures are mouse down/move events where we are interested which pixel was just clicked. While there is an event data node for the clicked coordinates these are relative to the front panel and translating them into image pixel coordinates is a chore and requires ~~jumping through flaming hoops~~ tweaks. (i.e. label yes/no? zoom factor? etc.)

However, there is a "Mouse" property for 2D images that has all the information directly in pixel coordinates and mouse button states. Currently, we need to read that property inside the mouse event to easily get the information we always (always!!!) want in such an event!

It would be cleaner if mouse events on pictures would output these mouse properties directly as an additional event data node.

Two clear advantages:

Cleaner code for those who know how to work with this property.
Stop sending newbies on a snipe hunt trying to figure out how to translate the current "coords" event data node into something useful for the intended task.

Here is an example where this idea would have helped

Here's a picture for the graphical thinkers!

Thanks for voting!

I work with PPLs quite a bit...and sometimes...I just want to rename them.

Libraries that depend on the renamed PPL will then be broken, as expected. Example here:

It would be awesome if I could simply go in, right-click on the missing dependency, and replace it with the newly named one. But...for whatever reason...this option is disabled. Instead, I find myself having to go in and manually replace each individual broken PPL call (VIs, typedefs, etc.). This is unnecessarily time consuming and error prone.

What is a strictly-typed reference?

A strictly-typed reference is a kind of reference whose type descriptor contains an inner, user-specified data type.

For example, a queue is a strictly-typed reference because it contains the data type for its elements, specified when creating the queue.

Here is a non-exhaustive list of such reference types:

- Queue

- Notifier

- User event

- DVR

- Datalog file reference

- Strictly-typed control refnum

- Strictly-typed VI refnum

- Shared variable

- Network stream (reader/writer)

- RT FIFO

- FPGA IO / register / memory / FIFO / handshake

- ...

Idea:

Add a new primitive that would output the inner data type of any strictly-typed reference.

Here is a design example of the primitive, which could be named "Get Contained Data Type of Strictly-Typed Reference":

It would work for all the strictly-typed references mentioned above.

Motivations:

The implementation of malleable VIs is sometimes limited (or made complicated) by the fact that we miss some basic "type operators", such as getting the contained data type of a strictly-typed reference. While this missing function could be implemented using some tricks for most strictly-typed reference types, it is for example impossible for user events (See this thread for more details).

Typical application:

A malleable VI that takes a user event (for its type) and outputs a newly created refnum with the same contained data type:

This simple code is currently impossible in the general case due to the nature of user events.

Remarks:

1. The output terminal of this primitive will have to be named exactly as the contained data type, which is crucial for user events.

2. The output would have the LabVIEW default value for the data type (False for booleans, 0 for numerics, "" for strings, ...).

3. The primitive could be placed in a dedicated "Malleable VI Tools" palette.

4. In case the FPGA-specific implementation creates a dependency to the FPGA module, we could have a separate primitive just for FPGA (and also for RT if required).

What do you think?

Regards,

Raphaël.

View All (8)

We know that LabVIEW has some magic that it uses for automatic error handling. What if LabVIEW could use such sorcery to enrich the error string flowing on the wire, with information about the originating source of the error -- specifically the VI Reference and GObject UID of the node where the error was introduced. Then a "fancy error dialog of the future" (TM) could utilize those UIDs to navigate directly to the node and highlight it (a visual effect to show which node it is). This behavior could be added to the Simple Error Handler and General Error Handler VIs, and maybe ever there could be a "LabVIEW Gems" vi.lib utility that can extract the VI Reference and GObject UID for use in other, 3rd party tools.

View All (3)

Especially when I use setting windows I normally transfer the actual settings from a setting-cluster or from global variables to multiple local variables and display the current settings in the front panel. After the user edited the settings of course the settings need to be transferred again to global variables or in a setting-cluster. So if multiple global or local variables are used, each variable need to be changed from read to write 1 by 1 by right click and selecting the action from the menu.

So I suggest to implement a function to change it at the same time for all marked variables, similar to property nodes.

The suggested procedure would be:

Mark variables with the mouse by holding "Shift" on the keyboard or drawing a frame
Right click to context menue
Change all to read / write

The feature would be consistent, because it is for example possible to create local variables of multiple controls at once with a similar procedure. (I just don't get in mind why the order is always upside down when I do this)

View All (3)

View All (1)

Property node for push button LED color

I want to be able to programmatically change the color of the LEDs on push buttons.

The colors[4] property will change the color of the housing, but not the LED itself.

This push button is one of the controls that is both a control and an indicator rolled into one.

In my particular case, I want to represent a third state. I have a valve that can be open, closed, or in transit.

There are two actuation states of open and close, but three indicator states.

I think making it a property I can control is a powerful solution. Not only will it solve my use case, but I can have all different colors of Booleans without needing to use Customize Control and the Control Editor to modify the colors.

Extra credit request: Can we make just the LED blink? Right now, the blinking property blinks the entire control, but wouldn't it be cool if just the LED blinked? This is what those same two controls look like when blinking:

Maybe it's a new property just for LEDs that's separate from "Blinking". I'd be okay with that if you want to preserve current behavior.

Here are some related Idea Exchange posts related to a tri-state Boolean. They're not quite what I want, but I thought I'd link to them for reference:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Tri-State-Boolean/idi-p/1139952

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Special-LED-control-with-three-states-Default-ON-OFF/idi-p/991307

Built-in DVR Call Wrapper

DVRs are extremely powerful, yet tedious to work with. Much of the coding is just a matter of following the exact same pattern over and over again, while making the code uglier. And I have yet to come up with a good way to reduce that coding overhead...

What if there was a built-in DVR call wrapper that allowed direct access to VIs?

The UI experience could be a hybrid of the Static VI Reference and Call by Reference functions: drop the "DVR Call Wrapper" on the block diagram, drag your VI into it, then wire it up directly.

It could have options for write and read-only. And it could have right-click options for changing default error behavior.

My standard use case would be class calls specifically, but I don't see a reason this couldn't be applied to any data type -- although some serious thought would have to go into expected behavior in terms of which terminal to treat as the DVR (although this could be dynamic based on which terminal a DVR is wired into, or maybe even settable on the wrapper).

A tool like this would likely save me countless hours of development time, and make it less likely that I'd make coding mistakes while writing routine code.

View All (2)

LabVIEW Idea Exchange

Defer panel update nodes should default to the current front panel

Class Browser should not duplicate search results for child properties of a parent class

Add structure on bare wires

Named Bundler/Unbundler nodes should resize to the right

Remove redundant path information in Project Explorer

Allow interface wire appearance to be inherited

Add/Remove Diagram Space Inside Structures Without Resizing the Structure

Problem

Proposed Solutions

Why This Matters

Add unbundle to wiring menu for clusters

Normalize terminals height for timed structures and FPGA nodes

No autogrow while typing

Add Debug Window (AKA revamped Breakpoint Manager) back to right-click menus on wires

Mouse events on 2D pictures should have an event data node for mouse information

Allow "Replace" of Broken PPL Dependencies

New primitive to get the contained data type of a strictly-typed reference

Automagically include GObject UID in error messages when running in the editor

Option Change all to read/write for multiple local / global variables

Add feature to rearrange cluster bundle / unbundle terminals

Property node for push button LED color

Built-in DVR Call Wrapper

Toggle selection of entire array with the spacebar